SRE系列教程 | 孙宇聪：来自Google的DevOps理念及实践（下）
上一期孙宇聪老师关于SRE基本概念和核心原理的线上分享一经推出就引起了小伙伴们的热烈关注，看来大家对SRE的相关内容很感兴趣呀。
今天小数继续为大家带来孙老师的第二次线上分享内容，探讨SRE的一些最佳实践和成功标准，希望大家阅读愉快并持续关注我们后续的SRE内容：）
接下来聊一聊SRE的一些最佳实践，我认为Google做得比较好的几点。
建设平台化服务体系
首先， Google现在是一个六万人的公司，涉及到的产品线可能一百多个，各个部门之间差距很大，而且Google全球几百个数据中心，有很多机器，它如何管理？如果按照国内公司的方式去管理早就累死了。因为国内很多运维部门从上到下什么都管，从买机器开始，一直到最上面安装服务器、调试，配网络，所以业务线、运维部门经常好几千人。Google做得比较好的一点就是它把一个东西横向切分，因为它很早之前就意识到很多部门或者很多人之间有共性？像现在国内有的公司也开始讲的，运维部门要输出能力，公司内部也要服务化，因为只有服务化才能让每个团队更加专业化。
所以回到Google这个平台上，我认为它实际上是不停的在切分，就是横向切分。首先最底下是所谓的资源供给层，就是相当于把数据中心这件事情真的当成了一个资源，可以服于用户。就是用户需要什么样的机器，配置架构怎么样，怎么设计数据中心，这些东西它都帮用户做好。有一个专门的团队去做这件事情，这个团队也有自己的研发，也有自己的运维，也有自己的operation、PM，什么都有。
往上是技术架构，技术架构是大家经常听说的Borg系统等，让一些比较通用的技术或者通用的架构都能形成平台式的东西。
再往上才是产品线，每一层实际上都有自己的SRE部门、运维部门，都是一个项目。所以把这个平台搭起来之后，上层的人可以越来越少关心底下的细节问题，一定程度的减少了他很多精力、减少了很多官僚主义上的问题。需要计算资源的时候就给资源，不是还要先去审批又买机器，什么样的机器，什么样的配置都不一样，所以整个公司是一个非常同质化的公司，很多业务底下共享的东西很多。工作在越底层的人如果能服务的人越多，就会产生一个所谓的放大效应。可能大公司都是这样的，它有平台化效应，底下的人可以搞出一个世界最好的数据中心，可以同时服务几十个产品线的业务；搞出一个更好的数据库，所有人都可以用，这是Google做得比较好的一点。
容量规划和容量管理
然后大家会发现在做一个业务层运维的时候，可以关注更高级的东西，不是关心买什么样机器，而是更多关心到底需要多少容量，这些容量应该在什么地方。在YouTube我们经常在办公室摆一个世界地图，大家经常会讨论这里有一个数据中心，那里有一个数据中心，然后讨论在这边放多少容量，在那边放多少容量，它们之间如何灾备，我们可以考虑这些更高级的、更抽象的东西。这样的好处是可以真正的做到容灾，就是所谓的N+M。就是如果平时需要的峰值流量是N，M是作为灾备流量或者是这个冗余流量。N和M到底是什么？很多公司连自己的N都不知道，从来没有说过我们到底要处理多少流量，有些领导说我们“双11”想来多大量的就来多大量，这怎么能搞好？
这个问题是运维部门独特的功能或者独特的角色，要负责将把这个东西确定下来，我们到底要承担多大的流量，要有多少冗余。接下来就是验证这件事情，到底有没有这样的能力，能不能处理这么大的流量或者这么大的需求？ Google有一个内部指标就是130%，比如可以处理1秒交易量是一百万，实际上集群的峰都是按照一百万的130%来处理。130%是负载均衡或者是一些外界波动导致的，它实际上是不平均的。我们可以说它是一百万条交易的负荷，但实际上不可能说一百万零一条这个系统就崩溃了。可以留一下窗口，留一些冗余量来处理一些操作中的未知性，还有一些特殊意外情况，所以130%是一个我们常用的指标。
在Google里面已经很少提灾备这件事情，就是对我们来说我们没有灾备容量，都是平均负载均衡的。可能有一些冗余，比如一个系统只能一千台机器，这一千台机器并不是说我有十台是不接受业务处理的，而是我们所有机器都是接受业务处理，只不过他们处理能力可能没有把所有的资源都用完。这也是Google有很多经验教训，如果一个东西老是不用的话，它就是坏的，你平时再怎么演习、怎么用，一到关键时刻它就过不去、它就是有问题，所以更多的时候压根不讨论灾备的问题，所有东西永远都是在线的，这也是为什么说想把Google.com给弄坏是一件非常困难的事情，得全球几百个数据中心同时出问题，才可能会出现不可用的情况。所以Google全球业务是不可能中断的，不管出现多大的自然灾害，它这个业务都是不可能中断的。可能只有局部地区受损，只有基础设施受损的地方，它才会有一些问题，所以这就是灾备。
实战演习
另外一个更关键的一点是做实战演习。刚才也提到了，SRE以业务小组为单位，每周都会做实战演习，整个公司实际上每年也会做一次非常大的实战演习。我可以举几个例子，Google很多地方都有办公室，有一年某个办公室食堂的菜有问题，导致所有人都拉肚子进了医院。这是Google总部啊，一万人、两万人这样。于是我们就提出这样一个问题，说如果这个地方没有人来上班了，网站到底还能不能正常运行啊？我也曾经问过百度、腾讯，他们所有人都在一个大楼里，如果大楼突然断网了，公司还运转不运转？这是一个很大的问题，不管是地质灾害问题、自然灾害、人文灾害，这些虽然听起来好像比较极端，但确实能考验出一个组织的业务持续能力。实际上这是Google做得比较好的一点。刚才说的都是比较夸张的例子，是比较大范围的。一些比较小的例子，比如这个系统就是你这个小组负责，你们这个小组到底有没有单点故障，这个人是不是能休假，如果一旦出现问题是不是所有人都能去解决这个问题。我们经常互相出题去做这种测试，然后去分享一些知识。我想这更多是一种风气吧。首先你认同这个目标，目标当然就是把这个系统建设得更可靠。认同了这个目标，接下来就是不停地去考验还有哪些漏洞，并确保整个团队其他人也有同样的知识，同样的技能去解决这个问题。
其实说到Google在这一点上，也有所谓的运动式演练。每年1、2月份都会组织一次运动式演练，整个公司所有部门都要参与。在这一个星期的时间里实际上公司是不干什么正经事的，所有人都想出各种各样的方法去测试或者去提高系统的可靠性。
ONCALL的正确姿势
刚才说的这种比较大的所谓实战演习，具体到工作的时候也有几个，就是我们的轮值制度值班。国内小公司都是没有轮值制度的，所有人手机24小时开机，随时打电话，随时得解决问题，一个箭步从被窝里爬出来，赶紧上去解决问题。实际上这跟Google不一样。Google的值班方式更多的是八个人每人值一个星期，值一个星期，剩下的时间你就自己去写程序、做工程研发。但是在这一个星期里，你必须能处理生产上发生的一切问题，这才是真正值班。只有你值班，别人休假了，这才是值班，否则就不叫休假，也不叫值班。所以Google有一个非常明确的规定，Google认为一个事故的正确处理或从发生到解决到事后解决需要六个小时，它认为需要六个小时。运维人员每次值班一般都是值十二个小时的班，大概从早上五点到晚上五点或者是从早上十点到晚上十点。因为它所有的值班都是由两地互相倒的，在美国有一部分，在欧洲有一部分，我们上班的时候我们值班，他们上班的时候他们值班。Google认为其实一天最多只能发生两次事件。不管什么样的系统问题，首先要保证一定要有足够的时间去处理问题。因为如果问题发生太频繁了，就像有些互联网公司，每天一上班这手机就开始“嗡嗡”在桌子上不停的响。一旦有一会儿不响了，就开始担心说这个监控系统到底是是不是坏了。
如果处理太多了，实际上就变成什么呢？两个比较重要的因素，第一个因素是你没有办法好好处理，你处理相当于就是上去敲一个命令，没有时间去想到底这个东西为什么会出现这个问题，以后怎么避免这个问题。所以这个叫（狼来了）效应，你on call的时候已经没有时间去思考了。第二个会发生“狼来了”事件。本来可能是两次完全不一样的事故，但是你上一次处理的时候，你发现重启就行了，下一次你就条件反射，出现这个问题的之后你又去重启了，但它实际上可能是另外一个问题，可能是完全不相关的问题，你重启可能导致这问题更糟糕。所以如果你总是用这种模式处理问题的话必然会出问题，早晚这个灾难会升级。本来是一个很小的问题，结果可能变成一个很大的问题。
运维重要一点是解决线上问题。很多软件工程师做运维会钻牛角尖，这个线上系统出问题了，比如商城里不能购买了，这时候如果钻到这个程序里考虑要这么写还是那么写，实际上是不解决线上的问题。作为运维这个职业或者作为运营这个职业来说，它唯一的目标就是要保证系统的正常。有的时候需要用一些比较low的手段或者是方式。比如在项目初期机器有问题，我们就把它们都停了，然后使用一些新的服务器重新搭起来。事实上也不知道这个东西为什么坏了，就把它放在这儿，先去解决生产上的实际问题。实际上我认为这是运维最大的价值。运维部门目标就是保证业务的持续性。
事后总结
接着是做总结，写一些事后总结。Google的事后总结都是非常专业的，是非常对事不对人的，它会非常详细地列出来在什么时间出现了什么问题，谁去操作的，他执行了什么操作，这个操作到底是解决问题还是没有解决问题，如果没有解决问题的话该怎么去确保不会去执行这个操作。这是一个循环往复的过程，是一个不停锤炼的过程。把解决问题当成一个职业来对待的话，所有事情都很好办了。这回出现这个问题，解决了一遍，然后发现执行了某些地方可能是系统给出错误的信号，可能是文档有问题，把它都一一解决了。下回再执行的时候，可能换了一拨人来执行这个，也能保证不会出现问题。这就是事后总结带来的最大利益。
SLO预估
最后说说SLO。SLO是运维部门的一个关键工具。服务质量实际上是运维部门唯一负责的事情。公司要求员工达到某某指标，那员工怎么去达到这一点？第一，要先帮助制定SLO，要用事实、数据去说明白达到这个服务质量到底需要多少投入、需要多少流程改进、需要多少系统改进。第二，要确保达到这个服务质量不会影响创新速度。这要有一个平衡的取舍，要用数据去说话，一个每天只能down一分钟的系统和一个每天可以down四个小时的系统，它所能承受的更新频率是不一样的，部署的要求和方式肯定都是不一样的，所以要围绕着这个去做，要把这些理念推行到研发部门和产品部门。最后就是把可靠性当成产品的一个重要组成部分，研发也得关心可靠性，他在写代码的时候得知道这个东西一定是要可靠的。把可靠性一直推到产品设计或者是业务层次去，它才能贯彻到底层的研发、运维，才能把它做好。
SRE模型成功的标志
最后就是说到底SRE成功还是不成功，实际上就是看这两条曲线。上面这条线是部署规模，大家都知道互联网的业务都是爆发式增长，它是指数型的。如果说按照常规的那种招聘曲线，直线性的，那么永远赶不上这个规模，所以运维事务必须要把它压下来。Google经常做这种统计，到底我们业务规模扩大之后，扩大了多少工单数量，然后出现了多少事故，造成了多大问题。实际上只有统计这个事情，才能知道你到底做得好不好。当这个系统成熟到一定程度之后，SRE的运维速度是固定的，甚至是越来越少的。只有做到这一点，才相当于把运维这个事情做好，剩下的时间或者剩下的精力才能去接手更多的业务、做更多的技术研发。
我分享的东西也到此结束了，谢谢大家！
继数人云容器管理面板Crane开源之后，小数有一个好消息告诉大家，数人云Mesos调度器Swan也加入了开源的大家庭！从此Crane不再寂寞，和Swan相亲相爱。开源的脚步从不停歇，下一个会是谁呢？
了解更多有关Swan请点击 " 阅读原文”